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SYSTEM  RELIABILITY 

S/36O-65  No.  1  under  HASP/MVT 


The  past  month  has  been  sad,  with  11. 3#  of  production 
time  lost  because  of  system  or  site  malfunctions.  The  MTBF 
was  only  7-5  hours,  comparable  with  last  November  when  the 
figures  were  18.7$  lost  time  and  4.3  hours  MTBF.  Since 
that  date  we  have  been  averaging  3  to  4$  lost  time  and  10 
to  15  hours  between  failures. 

The  main  source  of  problems  has  been  IBM  hardware, 
accounting  for  66.2 %  of  all  down  time.  Most  of  this  was 
attributed  to  a  fault  in  core  memory  which  vanishes 
whenever  a  fix  is  attempted  and  reappears  again  later. 

Air  conditioning  failures  accounted  for  16.1#  of  down  time 
despite  the  fact  that  we  have  both  primary  and  auxiliary 
systems.  Software  and  other  problems  accounted  for 
the  remaining  17.7$. 

S/360-65  No.  2  under  HASP/MVT 


As  on  System  1,  it  has  been  a  troublesome  month, 
with  9.6$  of  production  time  lost  because  of  system  or 
site  malfunctions.  The  MTBF  was  only  8.9  hours. 

Again  hardware  is  the  chief  source  of  problems, 
accounting  for  64.5$  of  all  down  time.  One  third  was 
because  of  hardware  problems  encountered  at  ASUT  when 
it  reopened  after  the  summer.  The  remaining  time  split 
evenly  between  Console,  Tape  Drive,  Card  Reader/Punch 
and  2314  disk  drive  problems.  These  problems  are  now 
apparently  solved.  The  remaining  problems  were  split 
between  Air  Conditioning  21$,  Software  13.8#  and  other 
0.7$. 


It  is  worth  noting  that  during  the  month  the  major 
changes  were  OS/MVT  Release  18.6  and  a  HASP  modification 
which  provides  a  more  efficient  means  of  servicing  the 
Undergraduate  Terminals.  These  changes  caused  most  of 
the  software  failures.  It  is  unfortunate  but  true  that 
such  changes  can’t  be  fully  debugged  without  putting 
them  into  production.  We  believe  we  have  now  overcome 
the  problems  and  we  thank  you  for  your  patience. 
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SYSTEM  RELIABILITY  (Cont’d) 

7094  II  and  1401 

This  system  continues  to  function  reliably.  The  1401 
had  minor  printer  and  reader  problems  and  the  709^  had  a 
fault  in  the  7631  Control  Unit  and  in  the  7111  arithmetic 
unit.  Both  of  these  problems  were  caught  early  before 
users  could  experience  problems. 

USER  OPTION  SERVICE  LEVELS  * 

There  has  been  a  decrease  in  both  RUSH  and  101  activ¬ 
ity  over  the  past  month  with  many  users  reverting  to  ASAP 
as  the  load  builds  up.  All  users  should  study  the  backlog 
notices  posted  at  two  hourly  intervals  in  the  input  area 
(Sandford  Fleming  Room  109)  when  determining  what  service 
level  best  suits  their  needs. 

Don’t  forget  Class  V  service  on  System  2.  It  is 
lightly  loaded.  Turnaround  on  this  system  is  normally 
as  fast  or  faster  than  RUSH  but  at  ASAP  prices,  for  jobs 
requiring  less  than  110K,  no  mounts  and  no  TIC0l4.disk  pack. 

The  workload  on  all  systems  will  now  be  escalating 
sharply,  with  a  corresponding  increase  in  turnaround 
times.  Nothing  will  be  gained  by  submitting  all  work 
at  RUSH  priority.  Use  this  service  level  only  when  it 
is  vital  that  output  be  returned  very  quickly. 

The  service  level  breakdowns  for  September  compared 
with  August  follow: 


Percentage  of 

total  workload 

September 

August 

RUSH 

(R,  S) 

16  $ 

21$ 

ASAP 

(A.B.E.C.D) 

55% 

IOI 

( I , J ,M) 

CTA 

CM 

35% 

100$ 

100$ 

*Def init ions 

Jobs  in  RUSH  Classes  R,  S  preempt  service  from  all  other 
classes . 

Jobs  in  ASAP  Classes  A,B,C,D,E  are  serviced  As  Soon  As 
Possible,  subject  to  preemption  by  RUSH. 

Jobs  in  101  Classes  I,J,M  are  run  only  If  the  systems 
would  be  Otherwise  Idle. 
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SYSTEM  CHANGES 


Irt  Newsletter  68  we  described  a  variety  of  system 
changes  which  were  being  effected,  most  of  which  per¬ 
tained  to  improvement  of  overall  turnaround  and  through¬ 
put  capacity.  Upgrades  to  HASP,  the  improvement  of  the 
undergraduate  terminal  High  Speed  Job  Stream  arrangements, 
upgrades  to  several  remote  terminals,  and  the  addition  of 
a  third  231^  disk  storage  unit  have  all  been  carried  out 
effectively.  The  full  benefit  of  the  third  231^  has  not 
yet  been  felt,  owing  to  tuning  difficulties  with  OS  Re¬ 
lease  18.6.  This  Release  is  now  operative  in  S/360  #2, 
which  has  experienced  some  degradation  in  reliability 
which  relates  in  part  to  this  Release.  Computer  Centre 
staff  and  IBM  specialists  have  been  very  active  in  helping 
us  towards  the  high  degree  of  reliability  previously 
experienced  with  System  2.  OS  18.6  may  then  be  cleared 
for  implementation  on  S/36O  #1. 

A  second  and  vital  part  of  our  systems  activity 
concerns  the  maintenance  of  the  computer  language  pro¬ 
cessors  themselves.  The  many  languages  supported  in  our 
system  are  all  serving  well  and  reliably,  with  only  a  very 
small  number  of  snags.  The  staff  of  the  Computer  Centre 
is  developing  improved  methods  for  investigating  and 
correcting  this  type  of  system  bug.  Since  these  bugs 
affect  the  users  directly,  in  comparison  with  the  indirect 
effects  of  operating  system  reliability  and  efficiency, 
this  work  is  considered  to  be  of  primary  importance. 


PRODUCTION  DATA 

Table  I,  which  shows  the  number  of  jobs  processed  for 
the  first  three  months  of  the  current  academic  year,  indi¬ 
cates  the  expected  upturn  in  activity  from  the  August  low 
point.  This  is  true  in  moderation  for  the  System/360 
services  and  more  strongly  for  the  High  Speed  Job  Stream. 
The  slump  in  709^  work  since  July  seems  to  be  levelling 
out  in  September. 

Table  II  provides  a  comparison  of  production  be¬ 
tween  the  months  of  September  1969  and  September  1970. 

The  trend  toward  S/36O  service  and  away  from  709^  is 
clearly  seen.  A  substantial  upward  trend  in  High  Speed 
Job  Stream  services  is  also  shown. 
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PRODUCTION  DATA  (Cont’d) 


The  September  production  figures  are  all  well 
below  the  total  capacity  of  our  systems.  By  and  large, 
user  departments  have  not  been  short  of  allocated  compu¬ 
ter  funds.  Turnaround  has  been  good.  Idle  capacity 
exists  particularly  in  the  7094.  Our  resources  should 
therefore  be  able  to  support  the  anticipated  growth  of 
demand  in  a  reasonably  graceful  style. 

Users  are  reminded  that  the  7094  and  the  Class  V 
HASP  job  stream  are  two  particularly  under-exploited 
resources.  Furthermore,  there  is  considerable  space 
available  for  the  online  storage  of  user  libraries  and 
data  files.  Anyone  who  can  place  their  files  into  the 
online  2314  disks  can  improve  his  own  turnaround  and  help 
us  increase  the  total  productivity  of  the  S/360  systems. 
The  Users’  Service  Group  personnel  will  be  happy  to 
discuss  with  you  how  best  to  exploit  our  various  re¬ 
sources  . 


Jul 

Aug 

Sept 

System 

S/36O 

12,780 

10,983 

11,058 

7094 

2,304 

1,666 

1,597 

HSJS 

12,748 

10,465 

24,067 

TOTAL 

28,532 

23,114 

36,722 

TABLE  I 


No.  of  Jobs  Processed,  July,  August, 
September,  1970. 
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PRODUCTION  DATA  (Cont'd) 


Sept . 69 

Sept . 70 

Change 

System 

S/36O 

4, 794 

11,058 

+131? 

7094 

4,413 

1,597 

-  64# 

HSJS 

14,705 

24,067 

+  64# 

TOTAL 

23,912 

36,722 

+  54? 

TABLE  II  Comparison  between  September  1969 

and  September  1970. 


PROBLEMS  WITH  THE  PDP-8/s 

The  PDP-8/s  media  conversion  system  has  recently 
proven  itself  unreliable  in  the  transfer  of  data  from 
paper  tape  to  magnetic  tape.  The  staff  of  the  Centre 
is  searching  for  both  long-term  and  short-term  relief 
from  these  difficulties.  We  are  increasing  maintenance 
service  to  this  machine  immediately  and  are  considering 
alternative  devices  to  permit  us  to  bypass  the  problem. 
A  very  limited  group  of  users  are  affected  by  these 
problems.  We  would  appreciate  any  affected  user  making 
his  problems  with  the  PDP-8/s  known  to  the  Operations 
Manager,  Mr.  Wickens. 
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SERVICE  SCHEDULES  FOR  THE  UNDERGRADUATE  TERMINALS 


November  1,  1970 

— 

April  22,  1971 

ASUT 

9:30  a.m. 

5:00  p .m. 

Monday 

through  Friday 

EUT 

*  9 : 30  a.m. 

10:00  p .m. 

Monday 

through  Thursday 

9:30  a.m. 

5:00  p .m. 

Friday 

and  Saturday 

*  NOTE:  EUT  will  be  closed  from 
for  System  Testing  from 
January  28th,  1971* 

6:00  p.m.  to  7:15  p.m. 
December  l4th,1970  to 

UTCC  PERSONNEL  CHANGES 


Effective  October  19th,  1970  Roy  Finlayson  will 
assume  the  duties  of  I/O  Supervisor,  in  place  of 
Harold  Wermel,  who  is  moving  to  Australia  at  the  end 
of  October. 

Ismay  Goodliff  and  Clement  Chow  departed  the 
ranks  this  month  but  UTCC  is  pleased  to  welcome  back 
Murray  Tucker  after  a  short  absence  and  to  extend  a 
welcome  to  newcomer  William  Cundiff,  from  the  U.S. 

In  mid-October  Miss  Ann  Couto  took  time  out  to 
become  Mrs.  Alfred  DeFazio  -  lucky  Alfred! 


SSBs  ISSUED 


55:70 


56:70:1 

2 


57:70 


SIMON70  Processor  Now  Available  Through  High 
Speed  Job  Stream 

Changes  to  MSGLEVEL  Default  Option  under 
Release  18.6 

Problems  with  PL/1  under  Release  18.6 
Schedule  for  Thanksgiving  Holiday  Weekend 
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BOOK  REVIEW 


Computer  Languages,  Peter  C.  Sanderson,  Philosophical  Library 
Incorporated,  1970. 

Mr.  Sanderson,  a  senior  lecturer  in  computing  at  the 
Wandsworth  Technical  College,  London,  England,  has  produced 
a  modest  volume  which  does  an  excellent  job  of  illustrating 
the  main  features  of  five  specific,  higher  level  computer 
languages.  The  five  languages  are  ALGOL  60,  FORTRAN,  COBOL, 
PL/I,  and  extended  Mercury  Autocode.  The  latter  inclusion 
is  an  outcome  of  the  national  origin  of  the  book.  At  best 
this  chapter  may  provide  the  greatest  interest  of  any  in  the 
volume.  The  North  American  reader  will  not  otherwise  be  dis¬ 
tressed  at  the  British  flavour. 

Three  initial  chapters  provide  a  general  introduction  to 
digital  computers,  a  similar  introduction  to  computer  program¬ 
ming  itself,  and  then  a  brief  treatise  on  the  notion  of  com¬ 
puter  languages.  These  chapters  are  satisfactory  as  essential 
stepping  stones  for  the  previously  uninformed  reader.  The 
active  student  or  practitioner  in  the  field  of  computer 
programming  may  cheerfully  branch  directly  into  the  chapters 
on  the  languages  themselves. 

No  one  should  expect  from  this  book  a  thorough  education 
either  in  the  subject  of  computer  programming  or  of  the 
specific  languages.  The  text  itself  does  not  hesitate  to 
point  out  how  easily  implementation-dependency  penetrates 
the  fine  ideal  of  universality  of  these  languages.  The  fly 
leaf  commends  the  book  "to  professional  people  who  may  wish 
to  write  the  occasional  program".  We  might  add  that  a  copy 
of  the  manual  for  the  specific  language  processor  would  also 
be  a  necessary  investment. 


Digitized  by  the  Internet  Archive 
in  2018  with  funding  from 
University  of  Toronto 


https://archive.org/details/computersciencen69cala 
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TECHNICAL  TIPS 


Some  Problems  with  DO  loops  using  IBM  S/36O  FORTRAN  IV 

Two  problems  have  been  encountered  recently  in  which 
users  have  violated  the  rules  for  DO  loops  and  have  encoun¬ 
tered  inconsistent  results  either  between  level  G  and  H  of 
FORTRAN  or,  for  a  particular  FORTRAN,  from  one  OS  Release 
to  another. 

1.  Transfers  into  an  inner  DO.  If  two  nested  DO  loops 
end  on  the  same  CONTINUE  statement  then  an  IF  statement 
in  the  outer  DO  cannot  cause  a  transfer  to  the  CON¬ 
TINUE.  This  is  because  it  is,  in  effect,  a  transfer 
into  the  inner  DO.  Although  this  coding  is  not  flagged 
at  compile  time  and  may  sometimes  work,  it  should  be 
avoided  as  the  results  cannot  be  guaranteed.  The 
correct  way  to  code  this  is  to  use  two  CONTINUE  state¬ 
ments,  one  to  end  each  DO  loop. 

2.  Last  statement  in  the  range  of  a  DO  loop.  This  cannot 
be  a  logical  IF  statement  containing  a  GO  TO  statement 
(709^  users  note  that  this  restriction  was  not  present 
in  709^  FORTRAN  IV) .  This  error  is  flagged  by  the  G 
level  compiler  but  not  the  H  level  one  at  present . 
However,  there  is  no  guarantee  that  future  Releases 

of  the  H  level  compiler  will  not  do  so  since  the  lang- 
ugage  manual  forbids  this  construction.  Users  conver¬ 
ting  709^  programs  should  use  the  recommended  procedure 
of  debugging  using  the  G  level  compiler  and  change  all 
flagged  statements.  The  time  taken  to  do  this  at 
conversion  time  is  well  worthwhile  and  could  avoid  much 
trouble  later. 

In  all  cases  where  the  user  is  in  doubt  he  should  refer  to 
the  section  PROGRAMMING  CONSIDERATIONS  USING  A  DO  LOOP  on 
pages  38  and  39  of  the  FORTRAN  IV  Language  Manual 
(IBM  Form  C28-6515-7) . 
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TECHNICAL  TIPS 


Use  of  File-Protected  Tapes  in  FORTRAN  Programs 

The  use  of  file-protected  tapes  in  FORTRAN  programs 
generates  an  operator  message  every  time  the  tape  is 
either  read  for  the  first  time  or  rewound  and  read  again. 
Some  jobs  generate  so  many  of  these  messages  that  the 
operators  have  been  cancelling  them. 

Under  Release  18.6  it  is  possible  to  suppress  these 
messages  by  using  the  IN  positional  subparameter  in  the 
LABEL  parameter  which  defines  the  data  set  on  tape  as  being 
one  which  is  read  only. 

E.G:- 


//FT01F001  DD  DSN=IC  .  MYDATA  ,DISP=0LD  aUNIT=2400  , 
//  V0L=SER=N123i4  ,LABEL=  ( 1  ,SL  ,  IN) 


Use  of  SORT  Verb  in  COBOL 


Issuing  a  SORT  verb  within  the  output  procedure  of 
a  SORT  verb  will  cause  an  abend  while  executing  a  STOP 
RUN  statement .  The  abend  occurs  in  the  SORT  module  and 
the  region  size  increases  by  48K. 

This  situation  should  be  avoided  by  COBOL  users. 
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TECHNICAL  TIPS 


Some  Tips  for  More  Efficient  Use  of  CPS 

In  recent  months  there  have  been  a  number  of  queries  and 
comments  about  the  execution  speed  of  the  Conversational 
Programming  System,  with  comparisons  being  made  to  commer¬ 
cially  available  services.  It  may  be  valuable  to  consider 
some  technical  features  of  CPS  and  other  systems. 

CPS  and  some  other  services,  including  APL,  operate 
interpretively .  That  is,  the  source  code  is  inspected  and 
acted  upon  more  or  less  directly  at  execution  time.  In 
other  systems,  a  compilation  step  is  required  first,  pro¬ 
ducing  conventional  object  code  for  the  subsequent  execution 
step.  The  interpretive  process  serves  particularly  well  in 
the  interactive  environment.  On-line  syntax  checking  and 
the  ability  to  change  coding  in  the  program  without 
recompiling  are  useful  attributes  of  this  method.  Execution 
speed  is  not,  however,  so  fast  as  the  conventional  compile/ 
compute  systems . 

Understanding  this  method  of  operation  should  help  provide 
a  better  appreciation  of  the  situations  where  CPS  can  be 
economically  used.  These  will  obviously  include  applications 
where  the  interactive  capabilities  of  the  system  are  necessary. 
CPS  can  also  be  used  in  debugging  PL/1  programs  or  testing 
algorithms  for  use  in  larger  programs  which  are  being  developed. 
CPS  should  not  be  used  for  high  volume  processing  because  of 
the  interpretive  nature  of  the  processor  described  above. 

Rather,  problems  of  this  nature  should  be  directed  to  the  High 
Speed  Job  Stream  or  the  standard  batch  job  processing  streams. 

The  variety  of  services  available  from  the  Computer  Centre 
allow  users  a  set  of  good  economic  alternatives. 

For  CPS  users  some  rules  and  hints  follow  which  should 
be  of  assistance  in  getting  maximum  service  out  of  the  system: 

1.  CPS  has  a  limit  of  3  pages  (about  12K  bytes  of  core) 
for  any  one  procedure  it  can  handle.  Increasing  the 
number  of  pages  available  to  a  user  account  or  sub¬ 
account  does  not  circumvent  the  3  page  limit  for  an 
individual  procedure.  This  means  that  3  pages  is 
an  absolute  limit  for  programs  coded  in  BASIC,  while 
in  PL/1  the  program  may  be  split  into  several  procedures 
and  the  overlay  feature  used; 
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Some  Tips  for  More  Efficient  Use  of  CPS  (Cont’d) 

2.  the  default  option  for  declaring  variables  in  PL/1 
is  dec(l4)  (i.e.  14  digit  precision  or  double  pre¬ 
cision  on  the  S/360).  If  your  problem  does  not  require 
this  precision,  both  running  time  and  space  can  be 
saved  by  declaring  variables  dec(6)  (i.e.  single 
precision).  In  BASIC,  all  variables  are  stored  as 
double  precision; 

3.  avoid  the  use  of  subroutine  and  function  procedures 
in  PL/1  wherever  possible.  When  they  have  to  be 
used,  remember  that  an  internal  procedure  is  imbed¬ 
ded  in  the  calling  program,  so  that  all  variables 
declared  in  the  main  program  are  available  to  the 
internal  procedure.  Pass  through  the  argument  list 
only  those  variables  which  are  to  change  each  time 
the  procedure  is  called; 

4.  avoid  the  use  of  many  DATA  statements  in  BASIC  as 
this  uses  up  part  of  the  3  pages  allowed  the  program. 

If  data  is  not  expected  to  change  frequently  it  is 
better  to  set  it  up  on  disk  as  a  separate  file  and 
read  it  as  required; 

5.  if  a  program  is  saved  and  subsequently  reloaded 
variables  will  contain  whatever  values  they  were 
assigned  when  saved.  Thus  it  is  possible  to  set 
up  data  which  changes  infrequently  in  the  program 
and  avoid  reading  it  every  time  the  program  is 
executed.  This  holds  for  both  PL/1  and  BASIC 
programs . 
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APPENDIX  A 

UNIVERSITY  OF  TORONTO  COMPUTER  CENTRE 
Sandford  Fleming  Laboratories 


ROADMAP  UPDATES 


The  following  two  pages  constitute  updates  for  the 
UTCC  ROADMAP,  last  published  in  Newsletter  67,  August  28, 
1970. 
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DIRECTOR 


ASSISTANT 

DIRECTOR 


Secretary 


Quality  Control 
Chairman 


OPERATIONS 

MANAGER 


Chief  Operator 

System  Custodian 

I/O  Supervisor 

Crew  Chiefs 

Data  Collection 
Supervisor 

Tape/Disk  Custodian 

USERS 

GROUP 

’  SERVICE 

MANAGER 

Supervisor  of 
Programming  Advisors 

System  Advisors 

Numerical  Analyst 

ADMINISTRATIVE 

MANAGER 

Design  Analyst 

Author.  Clerks 

Dr. 

J. 

C.  Wilson 

Room 

0 

r— 1 

Mr. 

C. 

A.  Ford 

Room 

105 

Mrs 

.  Ann  Herring 

Room 

105 

Mr. 

Peter  Vincent 

Room 

Room 

115A 

130 

Mr. 

A. 

J.  Wickens 

Room 

136 

Mr. 

D. 

Tough 

Room 

112 

Mr. 

D. 

Rauch 

Room 

112 

Mr. 

R. 

Finlayson 

Room 

108 

D. 

Burness 

Room 

112 

D. 

Hart 

Mr. 

L. 

Daniel 

Room 

113 

Mrs 

.  P. 

Armstrong 

Room 

111 

Mr. 

R. 

Williams 

Room 

128 

Mrs 

.  C. 

Davidson 

Room 

115A 

Mr. 

R. 

Soderstrom 

Mr. 

L. 

Chu 

Room 

129 

Miss  R. 

Choudhury 

Mr. 

R. 

Lemmens 

Room 

129 

Mr. 

J. 

Palter 

Room 

131 

Mrs 

.  R. 

Greer 

Room 

129 

Mrs 

Mrs 

.  M. 
.  C. 

Rankin 

Pidcock 

Room 

103 

SOFTWARE  SYSTEMS 
MANAGER 


Programmers 


Mr.  J.  R.  Swenson 
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FLOOR  PLAN 


North  Hallway 


Main  Computer  Rooms  111  &  106 


Edit  Room 

Input  Services 

1C  9 

Output  Services 

107 

Unit  Record 

108 

EUT  120 

-  115 

Program  Advisors 

115A 

Director’s  Office 

104 

Asst .  Director 

105 

Operations  Manager 

136 

Administrative  Manager 

131 

General  Office 

103 

4 


1C  8 


South  Hallway 

1 —  — 


107 


v~ 

106 
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\  136' 
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~vr 

105 

103 
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104 
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COMPUTER  RESEARCH  FACILITY 


1.  C.R.F. ’s  New  Offices. 

2.  Preparing  for  MFT. 


1.  C.R.F. 's  New  Offices 


CRF  has  moved  its  general  offices  from  room  SF2739  to  room  SF2740 
in  the  Sandford  Fleming  Laboratories.  The  new  offices  are  located 
directly  across  the  hall  from  the  old  offices. 

Since  several  telephone  numbers  have  also  been  changed 3  a  complete 
list  of  room  and  telephone  numbers  is  given  below. 


Room  Telephone 

Number  Number 

General  Enquiry 
Systems  Manager  (J.R.  McBride) 

Secretary  (Sue  Raab  ) 

Hardware  Support (C.  Stevens  ) 

Operations  (K.  Patnaik  ) 

Software  Support  (L.  Mi  Hand  ) 

Computer  Room 


2.  Preparing  for  MFT 

CRF  will  shortly  be  irnplemeting  an  0/S  360  MFT  II  system  on  the 
360/44.  This  will  necessitate  some  changes  in  JCL  and  operating 
procedures.  Courses  will  be  provided  for  programmers  using  CRF  to 
enable  them  to  make  the  necessary  changes  before  the  implementation  of 
MFT  II.  For  details  regarding  these  courses  contact  Mrs.  L.  Milland 
(5271). 


SF2740 

8946 

SF2740 

4086 

SF2740 

4086 

SF2770 

8853 

SF2770 

8853 

SF2750 

5271 

SF2770 

8858 

